Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for OTEL_INSTRUMENTATION_HTTP_KNOWN_METHODS #5197

Closed
wants to merge 19 commits into from

Conversation

ngruson
Copy link
Contributor

@ngruson ngruson commented Dec 21, 2023

Fixes open-telemetry/opentelemetry-dotnet-contrib#1731

If the HTTP request method is not known to instrumentation, it MUST set the http.request.method attribute to _OTHER.

Changes

  • Added KnownHttpMethods property to options classes. Populated from environment variables or programmatically.
  • Respect KnownHttpMethods in AspnetCore and Http instrumentation
  • Added unit tests

@ngruson ngruson requested a review from a team December 21, 2023 19:01
Copy link

codecov bot commented Dec 21, 2023

Codecov Report

Attention: 6 lines in your changes are missing coverage. Please review.

Comparison is base (6250307) 83.38% compared to head (1d08a17) 83.11%.
Report is 30 commits behind head on main.

Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff             @@
##             main    open-telemetry/opentelemetry-dotnet#5197      +/-   ##
==========================================
- Coverage   83.38%   83.11%   -0.28%     
==========================================
  Files         297      271      -26     
  Lines       12531    11987     -544     
==========================================
- Hits        10449     9963     -486     
+ Misses       2082     2024      -58     
Flag Coverage Δ
unittests ?
unittests-Instrumentation-Experimental 25.21% <93.25%> (?)
unittests-Instrumentation-Stable 25.23% <93.25%> (?)
unittests-Solution-Experimental 83.08% <93.25%> (?)
unittests-Solution-Stable 83.11% <93.25%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files Coverage Δ
...reInstrumentationMeterProviderBuilderExtensions.cs 100.00% <100.00%> (ø)
...eInstrumentationTracerProviderBuilderExtensions.cs 100.00% <100.00%> (ø)
...ry.Instrumentation.AspNetCore/AspNetCoreMetrics.cs 100.00% <100.00%> (ø)
...tation.AspNetCore/Implementation/HttpInListener.cs 89.43% <100.00%> (-0.15%) ⬇️
....Instrumentation.Http/HttpClientInstrumentation.cs 100.00% <100.00%> (ø)
...ntInstrumentationMeterProviderBuilderExtensions.cs 100.00% <100.00%> (ø)
...tInstrumentationTracerProviderBuilderExtensions.cs 100.00% <100.00%> (ø)
...elemetry.Instrumentation.Http/HttpClientMetrics.cs 100.00% <100.00%> (ø)
...tp/Implementation/HttpHandlerDiagnosticListener.cs 70.86% <100.00%> (ø)
...plementation/HttpWebRequestActivitySource.netfx.cs 80.93% <100.00%> (+0.15%) ⬆️
... and 2 more

... and 32 files with indirect coverage changes

Copy link
Contributor

This PR was marked stale due to lack of activity and will be closed in 7 days. Commenting or Pushing will instruct the bot to automatically remove the label. This bot runs once per day.

@github-actions github-actions bot added Stale Issues and pull requests which have been flagged for closing due to inactivity and removed Stale Issues and pull requests which have been flagged for closing due to inactivity labels Dec 29, 2023
@@ -125,6 +125,9 @@ public class HttpClientTraceInstrumentationOptions
/// </remarks>
public bool RecordException { get; set; }

internal List<string> KnownHttpMethods { get; set; } =
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this being set from OTEL_INSTRUMENTATION_HTTP_KNOWN_METHODS anywhere? I don't see a ctor accepting IConfiguration on this class so it is possible some prep works needs to be done to hook that up. LMK if you would like some help with that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct, that was still a to do.
I now made some changes to read from env variables as well and added a unit test for it.
Can you review?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A question I had:
When OTEL_INSTRUMENTATION_HTTP_KNOWN_METHODS is set to an empty string or something illogical like fooBar, http.request.method is still set to GET for example and not to _OTHER.
Do you think this is correct behaviour?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I pushed some changes to the branch. Sorry about that I needed to see how the code was working and then I just started messing around with it 😓

  • Refactored everything into RequestMethodHelper (instead of options classes). Reason for that is OTEL_INSTRUMENTATION_HTTP_KNOWN_METHODS should also apply to metrics. I didn't want to introduce metrics options classes where we don't have them and also didn't want the same code in 4 options classes 🤣 I think now it has better separation of concerns.

  • Your question above about fooBar. I took a look at the spec and it seems like OTEL_INSTRUMENTATION_HTTP_KNOWN_METHODS should fully override the default list. The way it was coded you could only pair down the list of known things. I switched it up so we respect whatever is specified by OTEL_INSTRUMENTATION_HTTP_KNOWN_METHODS. I would like @vishweshbankwar to sound off on this. He has more expertise in the area. But he is out until 1/15 so we'll have to wait a bit to get his review.

Comment on lines 96 to 100
#if NET8_0_OR_GREATER
public void SetHttpClientActivityDisplayName(Activity activity, string method)
#else
public void SetHttpClientActivityDisplayName(Activity activity, string method)
#endif
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is the #if needed here? Maybe an earlier change that was removed?

<Compile Include="$(RepoRoot)\src\Shared\Guard.cs" Link="Includes\Guard.cs" />
<Compile Include="$(RepoRoot)\src\Shared\Shims\NullableAttributes.cs" Link="Includes\Shims\NullableAttributes.cs" />
<Compile Include="$(RepoRoot)\src\Shared\Options\*.cs" Link="Includes\Options\%(Filename).cs" />
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: this could be simplified

Suggested change
<Compile Include="$(RepoRoot)\src\Shared\Options\*.cs" Link="Includes\Options\%(Filename).cs" />
<Compile Include="$(RepoRoot)\src\Shared\Options\*.cs" LinkBase="Includes\Options" />

@vishweshbankwar
Copy link
Member

I think we should not add this for now. OTEL_INSTRUMENTATION_HTTP_KNOWN_METHODS isn't supported in .NET8.0. @JamesNK Is there a plan to add support for overriding the known methods in .NET implementation?

@JamesNK
Copy link
Contributor

JamesNK commented Jan 17, 2024

Not at the moment. No one has asked for it yet.

If OTEL_INSTRUMENTATION_HTTP_KNOWN_METHODS was set, how would that information be passed to .NET? Would OTEL look for the env var and then call some .NET configuration API to config the known methods?

@vishweshbankwar
Copy link
Member

Not at the moment. No one has asked for it yet.

If OTEL_INSTRUMENTATION_HTTP_KNOWN_METHODS was set, how would that information be passed to .NET? Would OTEL look for the env var and then call some .NET configuration API to config the known methods?

If a config option would be added to .NET (assuming OTEL_INSTRUMENTATION_HTTP_KNOWN_METHODS cannot be directly supported within ASP.NET Core), Users would have to directly configure that option in the supported version of .NET. From the instrumentation library side, we would not support OTEL_INSTRUMENTATION_HTTP_KNOWN_METHODS environment variable.

Copy link
Contributor

This PR was marked stale due to lack of activity and will be closed in 7 days. Commenting or Pushing will instruct the bot to automatically remove the label. This bot runs once per day.

@github-actions github-actions bot added the Stale Issues and pull requests which have been flagged for closing due to inactivity label Jan 26, 2024
@vishweshbankwar
Copy link
Member

Closing this PR: See #5197 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Stale Issues and pull requests which have been flagged for closing due to inactivity
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add support for OTEL_INSTRUMENTATION_HTTP_KNOWN_METHODS in HttpClient and ASP.NET Core
5 participants